Currently, there is a growing number of WiFi public hot-spots (or Access Points—“AP”). These APs allow WiFi-enabled devices (which we refer to as STA) that are in their coverage area to Connect to the internet.
Some of the APs are operated as a business, service, or as part of a community, either with or without a charge to the STA's owner. Other APs are placed by individuals in their premises, but are not “locked”, i.e., they are “open”, allowing bypassing STAs to utilize them. Other APs placed by individuals are “locked” (or “closed”), thus not allowing passing STAs to utilize them.
As APs are being deployed in growing numbers, many individuals lock their APs for fear of unfair use of their network resources, and due to security concerns. For instance, there have been cases where a person places an open AP, and his neighbor uses this AP as its internet connection on a full-time basis without the consent of the first person, thus abusing and degrading the service of the first individual. In other cases, the neighbor hacked into the computer of the first person through the network. Thus, as time passes, most APs are either locked, or a payment is required to use them. Although the total number of APs and their area of coverage is growing fast, a larger percent of the APs are becoming locked and inaccessible to roaming STAs.
A prior art approach for allowing roaming customers to access the Internet is taken by Fon (www.fon.com). It allows individuals to download a new software into their APs, which makes their APs a pay-for-use APs for STAs that roam in their vicinity, and in addition, they receive a username and password for free access to other APs which are operated by Fon or utilize their software. It also allows users to enjoy part of some of the payments made by other users to use the network. However, roaming STAs are forced either to find an open AP, find an AP for which they have an account, or pay for access in case there is a pay-for AP.
It is an aim of the current disclosure to provide a system and a method for deployment of APs for the purpose of connecting STAs to the Internet.
Roaming customers that connect to an AP are often far from the AP and have borderline reception conditions. As a result, the connection quality is very poor, and the user may experience a slow service or no service at all. It is another aim of the current disclosure to provide a system and a method for improving the connection quality for roaming STAs.
Another aspect of this invention refers to systems and methods for fast handovers in wireless networks such as 802.11 networks, specifically in un-managed wireless networks, and more particularly such systems and methods which allow extremely fast handovers in these networks without any changes to existing 802.11 base stations. The invention also concerns efficient performance with regards to power consumption, coverage, security, installation, capacity and availability of wireless networks such as 802.11.
The invention can achieve these goals without any change to the WiFi access point.
Currently, there is a growing number of WiFi public hot-spots (or Access Points—“AP”). These APs allow WiFi enabled devices (which we refer to as STA) that are in their coverage area to connect to the internet.
Some of the APs are operated as a business, service, or as part of a community, either with or without a charge to the STA's owner. Other APs are placed by individuals in their premises, but are not “locked”, i.e., they allow bypassing STAs to utilize them. The cumulative connectivity provided by the APs is enormous and growing fast, thus, it is tempting to use this cumulative connectivity to compete with other wireless technologies. For example, it would be tempting to have a STA that looks like a cellular handset (i.e., a WiFi Handset, or WiFi Phone), where the WiFi handset uses the free connectivity to provide a “free” service that competes with or complements the cellular service.
One of the major difficulties of achieving this vision is that the coverage of a single WiFi AP is very small (about a few hundreds to a few thousands of square meters). When a user goes out of this area, his connectivity is lost. A natural naive approach to solve this problem is performing a handover (sometimes also called handoff) to another AP with a better radio connection to the user. Another approach is to have a handset which supports both WiFi and Cellular, and handover the conversation from WiFi to Cellular [See: WO 2004/036770], this way, WiFi extends the coverage of cellular, and conversation is handed over from WiFi to cellular, when there is no WiFi coverage. However, the problem of performing handover between one WiFi AP to another WiFi AP remains when appropriate cellular coverage is not available (or there is no cooperation from the cellular company). The same idea applies when cellular is replaced by other access technology, such as satellite communications.
The concept of handover is taken from cellular networks. Handovers usually work well in managed networks, such as cellular networks, campuses, or office environment., where the entire network is usually owned by the same operator.
The network operator in many cases chooses to add cells where coverage or capacity are needed. In managed networks, the APs (or the cellular cells) are synchronized and communicate with each other through a backbone, and are usually controlled by some other network entity (e.g., BSC—base station controller in cellular systems). For example, the APs can communicate with each other, for example using the IEEE 802.11F protocol—the Inter-AP protocol, which involves a RADIUS (Remote Authentication Dial In User Service, see RFC 2138, 2865, and 2866) server.
The APs can also employ a radio resource management such as IEEE 802.11K, or fast roaming using IEEE 802.11R, etc. However, in unmanaged networks, the APs can be deployed by many unrelated entities, such as by private individuals.
There is usually no entity that synchronizes the APs. The APs can be manufactured by various manufacturers, use various security mechanisms etc. In unmanaged networks, the handovers are typically very slow, as in the process of handover, it takes time for the STA to re-connect to the internet in the new AP (and it must disconnect from the previous AP). In such a handover in an unmanaged network, the IP address often changes. Therefore, a mechanism such as mobile IP must be used (as described later). This mechanism is limited with respect to the frequency in which the IP address can change, and a large latency (disconnection time) may result during the handover process. During the latency, the STA cannot receive any incoming messages.
A handover process is typically composed of the station STA connecting to a new AP, and disconnecting from the old AP. If STA is connected in parallel to both AP the handover is called soft-handover, and if STA first abandons the old AP and then connects to the new AP, the handover is called a hard-handover. Soft handovers require the ability of STA to communicate in parallel with at least two APs.
The process of connecting to a new AP is usually composed of the following steps:
1. STA performs a scanning process to discover neighboring APs.
2. STA chooses a new AP, and performs authentication with the AP, in which the AP verifies that STA is allowed to access the AP.
3. If the authentication is successful, STA performs an association process, in which the AP acknowledges that STA is connected to it (association requires the AP to allocate resources to the STA, and the 802.11 standard allows up to 2007 STAs to be associated with an AP).
4. Once STA is associated with the AP, the STA makes sure that it has all the information that it requires to communicate over the internet, for example, it must have an IP address, and it must update servers that govern its location (such as Mobile IP, as discussed later). In some cases, the user should go through a second authentication procedure (usually with a RADIUS server). Many times, this procedure is performed over a web interface, which is called a Captive Portal.
When a captive portal is used by the AP, the user needs to surf into the captive portal and perform a log-in to connect his IP address to the Internet. In some implementations, the user's web browser is forwarded to the captive portal regardless of the internet site that it tries to surf into. Some APs allow the STA to surf in some limited number of internet sites before they complete the second authentication procedure (for example, if the AP is in an hotel, it might allow surfing into the hotel's website, or affiliated news web sites).
The procedure at the captive portal typically includes authentication, payment, or agreeing to terms of usage. Once the authentication is completed, the IP address of the STA is connected to the Internet (usually by reconfiguring the firewall that controls the communications of the AP). Each sub-process takes time to complete, resulting in a total delay of over several seconds to complete the entire process.
In managed networks, Step 4 can be performed once in a certain amount or time (or for a certain area), as moving between APs of the managed network does not necessarily change the parameters of the STA such as IP address etc. However, in un-managed networks (and sometimes also in managed networks), the STA must gain a new IP address and other parameters, usually through DHCP (Dynamic Host Configuration Protocol, see RFC 1541). Completing the DHCP protocol can take up to several seconds. Sometimes, obtaining an IP is not enough, and a second authentication is needed. In other cases, a proxy server or a Socks server should be set for the communication. The entire process can consume a few seconds, which are intolerable in a streaming two-way application such as a voice conversation.
Many protocols that are used in the Internet require that the IP address of the STA would remain fixed during communications (for example, TCP—Transport Control Protocol, see RFC 793). However, a handover might result in the change of the IP address. This change of IP address causes a break in the communication as the communication needs to be restarted.
One solution to this problem is provided by the Mobile IP standard (see RFC 2002): in this solution the STA updates a server with its current IP address, every time that the IP address changes. As a preparation for roaming, the server allocates to the STA (in addition to the STA's current IP address) an IP address that remains fixed, even when the real IP address of the STA changes. This fixed IP address is also known as a “care of” address. From this moment on, the STA keeps the server posted of the real IP address of the STA, and the STA can use (in its communications with the rest of the Internet) the “care of” address (or its home address) as if it was its own fixed address.
Any IP data packet that is sent to the care-of IP address is tunneled by the Mobile-IP server to the current IP address of the STA. For packets originating from the STA to the Internet, the STA can tunnel the packets to the Mobile-IP server, which replaces the IP address with the care-of address. However, many times the STA can simply write its care-of IP address as the source address of the IP data packet, as many times, the source address of IP packets is not checked what-so-ever in the course of routing the IP data packet in the Internet.
The Mobile-IP solution can be applied as long as the handovers are not performed too often. However, it incurs the punishment of routing all incoming packets through a server, causing both an increased travel time for the data packets, as well as latency (or disconnection) for the time that the real IP address changed, but the server is not informed yet. If the round-trip-time of the packets between the STA and the server is longer than the time a STA stays with the same IP, this method fails, as by the time packets reach the reported location of the STA, the STA is already in another location.
For many applications, such as voice, it is of utmost importance to minimize the time spent on the handover process. The time consumed by the handover process is usually dominated by the scanning step (Step 1 as mentioned above), and by Step 4 (specifically in case of an unmanaged network). There are many solutions that address fast handovers in cellular networks, and a few solutions that address fast handovers in managed WiFi networks (for example, see: WO2004/054283, which reduces Step 1 (mentioned above) by selective scanning but requires modifying the AP). None of these solutions deal with the delay due to Step 4.
It is an object of this invention to provide very fast handovers even in unmanaged networks.
Another barrier for wireless applications is that WiFi coverage might exists, and security policy might allow the STA to connect, but the AP might be out of resources (for example, there are 2007 associated STAs, and therefore it has no resources left, or that it has a limited IP address space which was already allocated through DHCP, and it has no IP address to allocate). It is an object of this invention to provide a system and method that allows STAs to use the services of the AP even when some of its resources are exhausted.
Another barrier for many wireless applications is the complex configuration of wireless parameters of STA, especially the security parameters. A user that purchases a new STA and has an existing AP, might wish to configure his new STA to work with his AP. This configuration includes entering into the STA the encryption key and authentication key that would allow it to use the AP. Existing solutions require a change in the AP and STA, such that a special key can be pressed simultaneously at both ends to perform automatic configuration (like Buffalo INC's AirStation OneTouch Secure System—AOSS, or Broadcom's SecureEasySetup). Without such a solution, the user is usually forced to punch into his STA the security codes (which are typically long). The problem worsens when the STA moves between APs that use different security settings.
It is an object of this invention to provide for easy configuration on both levels: at the initial setup and while roaming.
Another barrier for many wireless applications is that WiFi coverage might exist, but it is locked and unavailable for use for the STA. It is an object of this invention to provide a solution for (legally) accessing locked APs.
Another problem with WiFi is that the WiFi protocol is not optimized for low battery consumption (compared to cellular protocols such as GSM). In current solutions, if the STA moves between APs and changes its IP, it must use mobile IP and inform an entity (server) in the network of its current IP (we refer to this process as “location update”, as the STA updates the network entity of its location). Frequent location updates exhaust the STA's battery. Another problem with frequent location updates is that they create a heavy load on the network and on the network entities that manage and keep track of the STA's location.
The situation in WiFi is very different from the situation in cellular networks in two ways. Both of the ways cause an increase in the number of location updates in WiFi: First, in cellular network, the cells are typically much larger than a “cell” that is created by a WiFi AP. Therefore, in cellular networks, there are fewer transitions between cells, and hence less location updates. Second, cellular protocols allow defining a “location area” that encompasses several cells, and the STA is required to perform location update only when moving between location areas, and thus reducing the number of location updates. Current WiFi protocols are not built to support location areas.
It is an object of this invention to provide a method that reduces the number of location updates required for STAs while moving between APs.
It is an object of the current invention to provide solutions to the above mentioned problems, using both a centralized (server based) approach, and also by providing a method for performing the solutions using a distributed peer-to-peer network. Therefore, no huge servers and no large investments are required.